Einheit 4 — Authentifizierung
Was du nach dieser Einheit weißt: Du kennst die vier gängigen Authentifizierungsverfahren für REST APIs, verstehst ihre Unterschiede und weißt welches Verfahren wann eingesetzt wird.
Authentifizierung vs. Autorisierung
Zwei Begriffe die häufig verwechselt werden:
Authentifizierung — Wer bist du? Das System prüft die Identität. ("Ich bin Jonas.")
Autorisierung — Was darfst du? Das System prüft die Berechtigungen. ("Jonas darf Kundendaten lesen, aber keine löschen.")
In der API-Praxis passieren beide Schritte bei jedem Aufruf — oft unsichtbar, weil sie in der Infrastruktur verankert sind.
Verfahren 1: API Key
Der einfachste Ansatz. Der API-Anbieter stellt einen Schlüssel (String) aus. Dieser wird bei jeder Anfrage mitgeschickt.
Im Header (häufig):
X-API-Key: abc123secretkey456
In der URL (seltener, weniger sicher):
GET /customers?api_key=abc123secretkey456
Im Authorization-Header:
Authorization: ApiKey abc123secretkey456
Eigenschaften:
- Einfach zu implementieren
- Kein Ablaufdatum (außer explizit konfiguriert)
- Wenn der Key kompromittiert wird, muss ein neuer ausgestellt werden
- Kein Nutzerkontext — der Key identifiziert eine Anwendung, nicht einen Menschen
Typische Einsatzgebiete: Einfachere APIs, interne Integrationen, Dienste ohne nutzerspezifische Berechtigungen.
Verfahren 2: Basic Authentication
Benutzername und Passwort werden Base64-kodiert im Authorization-Header mitgeschickt.
Authorization: Basic am9uYXM6bWVpblBhc3N3b3Jk
Der Teil nach "Basic " ist benutzername:passwort in Base64-Kodierung. Base64 ist keine Verschlüsselung — es ist nur eine Umkodierung. Jeder der den Header abfängt, kann den Wert trivial dekodieren.
Basic Authentication ist nur sicher wenn die Verbindung verschlüsselt ist (HTTPS). Über HTTP ist es dasselbe wie Passwort im Klartext schicken. In der Praxis: niemals HTTP + Basic Auth kombinieren.
Eigenschaften:
- Sehr weit verbreitet, von allen Systemen unterstützt
- Wird bei jedem Request mitgeschickt (kein Session-Konzept)
- Passwort muss sicher gespeichert werden
Typische Einsatzgebiete: Ältere APIs, einfache Server-zu-Server-Kommunikation, Confluence/Jira API, viele On-Premises-Systeme.
Verfahren 3: Bearer Token (OAuth 2.0)
Das heute vorherrschende Verfahren für moderne APIs. Statt Passwort wird ein kurzlebiges Token mitgeschickt.
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Das Token ist ein JWT (JSON Web Token) — eine Base64-kodierte JSON-Struktur mit Nutzerdaten und einer kryptographischen Signatur. Es enthält (unter anderem) wer der Nutzer ist und wann das Token abläuft.
Der OAuth 2.0 Ablauf:
1. Dein System schickt Client ID + Client Secret an den Token-Endpunkt
↓
2. Der Auth-Server antwortet mit einem Access Token (+ optional Refresh Token)
↓
3. Dein System schickt das Access Token bei jedem API-Aufruf mit
↓
4. Das Token läuft ab (typisch: 1 Stunde bis 24 Stunden)
↓
5. Mit dem Refresh Token kann ein neues Access Token geholt werden — ohne erneute Anmeldung
Eigenschaften:
- Access Token ist kurzlebig — Kompromittierung hat begrenzte Auswirkung
- Client Secret muss sicher aufbewahrt werden
- Token enthält Scope (was darf dieses Token)
- Komplexer zu implementieren, aber industriestandard
Typische Einsatzgebiete: Microsoft Graph API, Salesforce, Google APIs, moderne SaaS-Systeme.
In 42°OS: Access Token im Credential-Store speichern. Separater Workflow der Token regelmäßig erneuert und ins Credential-Store schreibt.
Verfahren 4: API Key + Secret (HMAC-Signatur)
Fortgeschrittenes Verfahren: Statt den Key direkt zu schicken, wird damit die Anfrage kryptographisch signiert.
Authorization: HMAC-SHA256 Credential=myKeyId, Signature=a3f9b2...
Der Server berechnet dieselbe Signatur und vergleicht. Niemand der den Netzwerkverkehr mitliest kann die Signatur wiederverwenden, weil sie den Zeitstempel und den Request-Body einschließt.
Typische Einsatzgebiete: AWS API, Stripe, sehr sicherheitskritische Systeme.
Übersicht und Entscheidungshilfe
| Verfahren | Sicherheit | Komplexität | Wann |
|---|---|---|---|
| API Key im Header | Mittel | Sehr gering | Einfache APIs, interne Tools |
| Basic Auth | Mittel (nur mit HTTPS) | Gering | Ältere Systeme, Confluence/Jira |
| Bearer Token (OAuth 2.0) | Hoch | Mittel | Moderne SaaS-APIs |
| HMAC-Signatur | Sehr hoch | Hoch | AWS, Zahlungsdienstleister |
Wo Credentials in 42°OS gespeichert werden
Alle Zugangsdaten — API Keys, Passwörter, Client Secrets, Bearer Tokens — gehören in den Credential-Store der Plattform. Niemals direkt in die Agent-Konfiguration schreiben.
Im Post Agent wird der Credential-Name referenziert:
Authorization: Bearer {% credential mein_api_token %}
Der tatsächliche Wert wird verschlüsselt gespeichert und erst zur Laufzeit eingesetzt. Er erscheint nie im Klartext in Logs oder Konfigurationen.